Architectures for Widget-Level Plasticity

User Interface WAHID, WML[8], JavaServer Faces[20] PIMA [2] AUI[17], UIML [1], XSL/XSLT [24, 23] CGB [6] L ev el o f U I S pe ci fic at io n Concrete User Interface Visual C++, Visual Basic, JBuilder Table 1. A classification of interface development tools. Tools in italics are production quality. Figure 6 demonstrates the WAHID/E deployment of WordPad, a simple word processing application provided with the Windows operating system. After doubletapping the stylus pen in the WordPad application window, the user is presented with a pie menu (figure 6(a)) populated with the top-level WordPad menu items (File, Edit, View, Insert, Format, Help). Figure 6(b) shows the user selecting the ‘Open...’ item from the ‘File’ menu. The pie menu fires the appropriate command associated with the ‘Open...’ item in the File menu to the WordPad application. The external architecture provided in figure 5 can be generalized to allow the use of any electronic whiteboard widget in a legacy application. The widget container and pie menu components can be grouped together as an external widget component. The mouse hook and gesture router can be grouped together as a gesture handling component. The mouse can be replaced by a generic input device component. The flow of events among the new components remains the same. 4 Classifying Widget-Level Plasticity Widget-level plasticity trades off usability versus expressiveness. Our approach is therefore appropriate for application development where it is possible to restrict plasticity to just the widgets. In applications intended for a wide range of platforms with fundamentally different properties (e.g., PC versus mobile telephone), the widget-based approach is insufficient. To better understand the domain to which widget-based plasticity should be applied, we compare the WAHID approach to other modeland language-based approaches for plasticity. This comparison is summarized in table 1. Loosely following the framework of Calvary et al. [5], the classification is based on three axes: level of user interface specification, degree of automation and production quality. Level of user interface specification describes the level of input artifacts to the development tool or method. This ranges over three levels: Concrete User Interface: A concrete user interface (CUI) precisely specifies the application’s presentation and behaviour. CUI’s are therefore platform-specific. The most basic form of plasticity is therefore to develop a separate CUI for each target platform, using traditional tools such as Visual C++ or Visual BASIC. Abstract User Interface: An abstract user interface (AUI) specifies the structure of a user interface’s presentation and behaviour, but does not bind the behaviour to a specific platform. For example, the Wireless Markup Language (WML [8]) provides an abstract “Select” tag that allows users to select from a list of elements. The selection list may be rendered as a list of checkboxes or a menu depending on the platform on which the WML is rendered. An AUI must be transformed into a concrete user interface for use on a particular platform.User Interface: An abstract user interface (AUI) specifies the structure of a user interface’s presentation and behaviour, but does not bind the behaviour to a specific platform. For example, the Wireless Markup Language (WML [8]) provides an abstract “Select” tag that allows users to select from a list of elements. The selection list may be rendered as a list of checkboxes or a menu depending on the platform on which the WML is rendered. An AUI must be transformed into a concrete user interface for use on a particular platform. Models: Domain, task, platform and interactor models are used to describe the purpose and context of use of the application. From these high-level models, an AUI is developed, from which a set of CUI’s can be derived. Degree of automation describes the level of developer input in the process of reifying one level of specification to the next. Reification involves translation from high-level models to the AUI, from the AUI to the CUI and to the interface implementation. Degrees of automation range over Automatic, where the developer provides no input to the process. For example, in JavaServer Faces, developers program with abstract widgets matching a specified interface. One a concrete platform, these widgets are reified as concrete widgets that implement the interface. Automatic with developer intervention, where the developer is able to influence the reification, or tune its output. Much of the contribution of modern model-based approaches is their provision of opportunities for developer intervention. Write-once, where the developer provides a specification for how to map from high-level model/AUI to a platform, and this specification is used each time the model/AUI is changed. For example, to transform XSL [23] abstract user interfaces to a specific platform, developers write an XSLT [24] transform once. Manual, where the developer manually performs the translation from one level of specification to the next with no tool support. For example, the User Action Notation (UAN [7]) is used to specify task and dialogue structure, from which a concrete user interface may be created by hand. In table 1, tools indicated in italics are production quality, meaning that they have been applied to the development of commercial software. The WAHID approach to widget-level plasticity is classified as an automatic tool that begins with an AUI specification of the user interface. Automatic tools are able to reify an AUI into a platform-concrete interface without developer intervention. MOBID [16], HUMANOID [21], MASTERMIND [22], ArtStudio [5] and TRIDENT [3] are all tools that provide a mix of automatic translation and developer input. Languages such as WML [8], UIML [6] and XSL/XSLT [24, 23] begin their interface specification at the AUI level. UIML and XSL/XSLT are write-once tools which allow developers to write transformations that can be reused in reifying AUIs to platform-concrete interfaces. 5 Evaluation of Widget-Level Plasticity Widget-level plasticity allows developers to create plastic applications for a limited platform domain. The domain of applications supported by our WAHID approach consists only of desktop PC, electronic whiteboard and tablet PC applications. The limited domain supported by widget-level plasticity can be attributed to two factors. First, a widget-level plastic application can only change the appearance and behavior of its widgets, not its entire appearance. Supporting plasticity on platforms such as the PDA and cellular phone requires plasticity at the applicationrather than widget-level. Second, as can be observed from table 1, automation in interface generation is generally provided at the cost of support for a limited domain. Providing automation on a large domain of platforms can bring about interfaces with unsatisfactory layout and appearance. This is because the less involved the developer is in the interface generation process, the less able a tool is in reasoning about which widgets to use and how to lay them out in the interface for a particular platform. In the WAHID approach, the external architecture allows developers to incorporate plasticity in applications without changing the application code. The developer must only ensure that the external architecture components are able to communicate properly. The external architecture requires that the standard PC widgets continue to appear after the electronic whiteboard widgets are rendered. This wastes screen real estate and may confuse users. Further, some widgets, such as the Horseshoe scroll bar, cannot be implemented under the external architecture. The Horseshoe scroll bar must be rendered in a specific location when the application is first executed. It is not practical to allow the Horseshoe scroll bar to be activated through gestures. The internal architecture allows developers to incorporate plasticity in new applications by requiring a minimal amount of change to the application code. Using the internal architecture, developers are able to incorporate plasticity in their applications using familiar interface development techniques. The internal architecture is specific to the MFC framework, but might be generalized to apply to other frameworks. The WAHID architectures resolve the architectural mismatch between the architectures required to implement widget-based plasticity and that of MFC. To adapt WAHID to other widget toolkits would require the resolution of similar architectural mismatches. The WAHID internal architecture deploys its plasticity framework between the application’s view class and the MFC framework view class. Other frameworkspecific internal architectures must be able to deploy their plasticity frameworks at the appropriate level in the framework. A disadvantage of the internal architecture is that the application code must be available and open for change. The developer must also ensure that the application software architecture incorporates the internal plasticity framework. This is to avoid performing significant changes to the application code when deploying the internal architecture plasticity framework.